• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    An electronic masking and tagging engine is proposed for masking and uniquely signing database contents and database source code, wherein a database source code comprises SQL code and PL-SQL code as the host language. The SQL commands are included in appropriate places in the source code, either through procedure calls or as plain text commands that are translated by a precompiler into host language procedure calls. By means of a loading process, the masking and labeling engine reads plaintext keywords from the source code and generates dynamically, in real time, an encrypted keyword according to the PL / SQL rules. Using the masking and labeling engine, the plaintext keyword is substituted with the encrypted keyword and the entire masked PL / SQL source code is piecewise stored in a relational table, with the encrypted keywords being correctly interpretable by the Oracle PL / SQL Engine.
    公开号:CH712679A2
    申请号:CH00878/17
    申请日:2017-07-06
    公开日:2018-01-15
    发明作者:Putrino Nunzio
    申请人:Futureltcom Gmbh；
    IPC主号:
    专利说明:

    description
    Technical Field The present application relates to electronic engines for the automated masking and unique signing of database contents and database source code, in particular a system and method for maintaining the confidentiality of information in databases, in particular SQL (StructuredQuery Language) and PL / SQL ( Procédural Language / Structured Query Language) databases, as well as the source code and primary code of the corresponding databases.
    State of the art Many database manufacturers, e.g. Oracle, headquartered in Redwood City, California, with its database product Oracle Database, deliver what is known as a wrapping utility. Wrapping utilities are usually updated with each release, as explained in more detail below. The purpose of this utility is to mask the PL / SQL source code to make it illegible for third parties. The state of the art and the invention are explained below using the Oracle database, but can also be transferred to other databases.
    Typically, a database application never consists exclusively of SQL scripts (SQL: Structured Query Language), but is written in a so-called host language, such as C ++, Delphi, Java etc. SQL commands are at the appropriate place embedded in the source code, either by procedure calls or as plain text commands, which a precompiler translates into procedure calls in the host language. PL-SQL (Procédural Language / Structured Query Language) is one such host language. The interaction of the various engines is important, i.e. in this example from SQL and PL / SQL, at the coding level. The boundaries between the SQL engine and the PL SQL engine should be as closely interwoven as possible, so that there is in particular the smallest possible difference between the data types and built-in functions of both environments. This also applies to any other host language that is also converted accordingly. Each time an SQL command is executed in a PL / SQL procedure, this leads to a context switch. A characteristic of PL / SQL is that it is very database-oriented, has no graphic output and only has limited text output options. In practice, this often leads to a division of tasks. A language other than PL / SQL is used as the host language, from which SQL commands are executed and / or PL / SQL constructs are called. In this way, the actual database logic and technology is formulated in PL / SQL, while the rest of the source code is in a third language. For PL / SQL, it is usually an interpreted language, i.e. the source code is not translated into machine code, but into an intermediate layer, the so-called M code, which is only interpreted and executed by the PL-SQL engine at runtime. This makes the object code platform-independent, which, however, shows a certain performance disadvantage compared to completely compiled languages. PL / SQL and SQL are largely coordinated. The PL / SQL data types largely correspond to the SQL data types. However, there are also deviations. Remote calls of PL-SQL routines are possible as long as a database link to the relevant database is possible. The execution takes place on the remote database. Some of the supplied PL-SQL packages are critical from a security perspective, since they can be executed in a standard database by any user. However, access can also be prevented because execution rights can be specifically assigned to individual users. All PLSQL objects can be queried via a view dba_object. The source code is available via dba_source and the parameter lists via all_arguments. As with the views, it also applies to the creation of PL / SQL objects and triggers that the necessary rights must be present as direct rights, since indirect permission via a role is not sufficient. Additional information for debugging purposes can be stored in the M code for each PL / SQL object. Execution rights on the dbms_debug package are also required for debugging.
    As mentioned, the source code of a PL-SQL object can be protected by wrapping by wrapping the object, i.e. wraps. This means that the actual source code is replaced by the M code mentioned. In this way, an application can be delivered to third parties without having to look into the source code. The source code can then no longer be viewed using the dba_source view mentioned above. It is not possible to import a PLSQL object into a database and subsequently carry out wrapping. Instead, the object definition is wrapped within a script, which is then imported.
    When wrapping, a new script is created from the original script create_procs.sql. All create commands for functions, procedures, packages, package bodies, types and type bodies are translated into the M code, while all other commands remain unchanged. Only the script create_procs_wrapped.sql is then imported. Since it is not possible to restore the source code from the M code, the original script must always be maintained for an update and then re-wrapped for delivery. The following points are crucial in connection with wrapping: (i) SQL commands embedded in the PL / SQL code can be made visible despite wrapping by SQL trace of the application or by inspection of the view v $ sql; (ii) It is possible to export and import veiled PL / SQL objects using data pump or conventional export / import. The objects remain covered; (iii) The source code of triggers cannot be hidden. Instead, a separate procedure for the trigger source code must be written and the wrapping carried out afterwards. The trigger then calls this procedure; (iii) Passwords or other values that are built into the source code as constants or as default values for variables are not encrypted by the wrapping, but also appear in the wrapped code
    CH 712 679 A2 in plain text. In such cases, the password should be encrypted and saved in an appropriately protected database table or operating system file. Various encryption and decryption algorithms are available via the dbms_obfuscation_toolkit or dbms_crypto package, including: DES, 3DES, AES, MDS and SHA-1 etc .; (iv) The database into which a veiled object is imported must be of the same or a newer version than the database in which the wrapping took place. It is usually not possible to import into an older database version.
    For the example of the Oracle Database and PL-SQL objects applies that Oracle delivers a corresponding wrapping utility with each release, which allows the PL / SQL source code to be masked in order to make it illegible for third parties. The respective Oracle release PL / SQL engines are then able to process the masked PL / SQL source code. A decisive disadvantage of wrapping technology is, however, that the author David Litchfield (see eu.wiley.com/WileyCDA/WileyTitle/productCd-0470080221.html) utilities, how the unwrap.py utility has implemented and made available to the public (see blog.teusink.net/2010/04/04 unwrapping-oracle-plsql-with-unwrappy.html). Thus, the basic idea of Oracle to mask the PL / SQL code for third parties is completely questioned. In addition, the decryption engine is very easy to find on the Internet. It is enough to type the word “unwrap it” in any search engine, to copy the masked code into the form intended for it, in order to get the source code in plain text (cf. technology.amis.nl/2009/02/03/ unwrapping 10g-wrapped-plsql /). David Lichtfield's original idea has led to further developments, so that even the IDE (Integrated Development Environment) PL-SQL developer itself is misused to make complete sequences of PL / SQLSource code readable again at the push of a button.
    Another developer Pete Finnigham (www.petefinnigan.com/weblog/archives/00001385.htm) counteracted this tendency with an appropriate instrument in order to be able to mask PL / SQL code nevertheless. The technical disadvantage and the difficulty of this tool are that the process acts at the file level (export source code from the database to files) and only on one file that stores the PL / SQL code. In addition, various auxiliary files are required, such as "omit-file", in order to inform the obfuscation engine which key words may not be masked under any circumstances. In addition, the end user must update a “reserved word file” from each Oracle release to the next Oracle release so that Pete-Finnigham's engine leaves the reserved Oracle keywords untouched. Finally, the end user has to come up with two encryption keys, which can be used to encrypt the PL / SQL source code. Another disadvantage is that with a simple parser, which contains the command "select <concatenated ASCII characters> from dual;", sequences of concatenated ASCII characters can be reconstructed as plain text. The Pete Finnigham process is still clear for small PL / SQL packages (three to five packages). As soon as PL / SQL libraries have to be masked, time and effort increase enormously to create and maintain the respective Omit and other necessary help files. In addition, the error rate and effort for bug fix in the encrypted code increases disproportionately, almost exponentially, with the size of the libraries.
    Technical object It is an object of the invention to provide a technical solution which does not have the disadvantages discussed above. In particular, the solution should make it possible to be able to mask PL / SQL code despite the existing un-wrapping possibilities. In addition, the technical effort and time required (necessary number of commit and auxiliary files; necessary passwords; necessary release-related updating of files, etc.) for the wrapper engine in order to deliberately mask the PL / SQL source code should be correspondingly small be or be completely eliminated without simply allowing third parties to unwrap the code.
    Summary of the Invention According to the present invention, the above objects are achieved in particular by the features of the independent claims. Further advantageous embodiments can be obtained from the dependent claims and the description.
    [0010] According to the present invention, the above-mentioned tasks for an electronic masking and labeling engine for masking and unambiguously signing database contents and database source code are achieved in particular in that a database source code comprises SQL code and PL-SQL code as the host language , whereby SQL commands are integrated into the source code at appropriate points. Either through procedure calls or as plain text commands, which are translated by a precompiler into procedure calls in the host language, that the masking and labeling engine reads plain text keywords from the source code using a loading process and dynamically, in real time, an encrypted keyword generated according to the PL / SQL rules, and that the masking and labeling engine replaces the plaintext keyword with the encrypted keyword and the entire, masked PL / SQL source code is stored piece by piece in a relational table, the encrypted Keyword can be interpreted correctly by the Oracle PL / SQL Engine. The invention has the advantage, among other things, that the masking and labeling engine according to the invention is particularly suitable for combining the strengths of Java, PL / SQL and the Oracle relational database, and at the same time compensating for the respective weaknesses of the individual technologies. Using the masking and labeling engine, e.g. strings are automatically inserted into the code, the code with inserted strings by the Oracle PL / SQL Engine
    CH 712 679 A2 is interpreted correctly. Access to the respective user scheme, which stores the entire electronic masking and labeling engine, can e.g. only by means of predefined, sharp roles, which are assigned to certain, identified end users of the engine. Access to the respective user scheme, which stores the entire electronic masking and labeling engine, can e.g. by means of the predefined, sharp roles according to the security rules of a particular database provider. Access security to the electronic masking and labeling engine can e.g. can be increased by storing a «transparently encrypted» mechanism in the respective storage medium and integrating it with the masked, created PL / SQL source code in the orderly backup-restore recovery process. After masking the source code using the masking and labeling engine, e.g. either a single PL-SQL package, which is suitable to create individual patches within a library, or export an entire library as a single stream to a zipped file ready for dispatch. For users of the PL / SQL code using a historization and versioning mechanism, e.g. The pair (plaintext keyword; encrypted keyword) can be reconstructed at any time, whereby it is possible for users to determine when, for which end user or customer, in which PL / SQL package the substitution plaintext keyword »with« encrypted keyword »took place Has. In the same table in which each pair (plaintext keyword; encrypted keyword) is stored, e.g. each pair should have a time stamp. The entire masking and labeling engine can e.g. be implemented in Java and / or another, object-oriented programming language, the engine as byte code and as completely non-transparent and irreversible code for users being completely embedded in the PL / SQL code and executable by the PL-SQL engine. The table containing the keywords to be masked can e.g. can be filled in an analogous manner with plain text passwords, after which the encrypted and dynamically generated passwords can be sent from machine-to-machine in order to automatically and / or according to a schedule and / or according to the schedule on local or delocalized machines and / or applications Random change. The masking and labeling engine can e.g. generate a plain text keyword and / or password consisting of a single character an encrypted keyword or password of 29 characters according to the PL-SQL Engine rules from the Oracle Database, whereby the maximum character length of 29 characters is determined by the Oracle Database and cannot be exceeded , and if added, a character to the encrypted string of the Oracle-PL / SQL engine blocks any further execution The encryption engine can e.g. be implemented separately from the inventive masking and labeling engine and be embedded and operated with the same mechanism in a PL / SQL code. Finally, it should be added that the technical structure of the present invention has a cross-territorial application both in the loT world (Internet of Things), robot-robot or machine-to-machine communication, in particular for the prevention of data and software theft, Improvement of refresh mechanisms for open protocols such as the OAuth protocol (eg OAuth2.0 protocol), in connection with block chain eg when using biometric personal keys or with authorization / authentication login mechanisms. This universal applicability cannot be realized in this way with any known system or method of the prior art. Since open protocols such as the OAuth in particular allow standardized, cross-technology, secure API (Application Programming Interface) authorization for desktop, web and mobile applications, the combination of the present invention with such open protocols results in a correspondingly broad applicability and applicability.
    Brief Description of the Drawings The present invention is explained in more detail by the following examples with reference to the drawings, in which:
    Fig. 1 shows schematically an inventive electronic masking and labeling engine for masking and unique signing of database content and database source code, as well as a component overview for the operation of the masking and labeling engine and for creating the ready-to-ship masked PL-SQL source code. Steps 1 and 2 show the masking and labeling engine, which is loaded in a predefined user schema with the loadjava utility (2) from the Oracle Database. Step 3 shows how all operations for masking the plaintext PL-SQL source code take place within a predefined Oracle user account. Step 4 shows how the parameterized methods make it possible to create individual PL / SQL packages or an entire library in the referenced order of the PL / SQL packages. Step 5 finally shows how the masked PL / SQLCode is zipped ready for dispatch.
    Fig. 1 thus illustrates the basic structure and operation of the electronic masking and labeling engine from delivery, as a zipped WAR file, to the extraction of either any file or patch or an entire library (5) from the Oracle Database. The files are stored in an archive and zipped for a specific end user, ready for dispatch using the usual transfer channels (mail attachment, SFTP (Secure File Transfer Protocol), download from a repository).
    2 schematically illustrates the transfer of a masking and marking engine according to the invention as a zipped jar file. 2 thus shows how an end user obtains the electronic masking and labeling engine. The unzipped archive contains all other programs for the installation and operation of the electronic masking and marking engine and the installation guide as shown in Fig. 3 (unzipping the file "deliver_release_1_1_20160202").
    CH 712 679 A2 [0015] FIG. 3 shows, by way of example, the unzipping of the file “deliver_release_1_1_20160202”.
    Fig. 4 shows an example of an electronic masking and labeling engine according to the invention, which is embedded as Java byte code using the loadjava utiIity from Oracle in the user scheme. That the masking and labeling engine is developed outside of an Oracle database using the common Java development tools. The plain text Java source code is never loaded into any Oracle database (see Fig. 4). Common Java tools are sufficient to create a jar file from the individual, referenced Java classes. The jar file is stored in a directory to be loaded into the database using the Oracle loadjava utility.
    Fig. 5 shows an example of a confirmation of the successful loading process of the java byte classes from the jar file in the database. Fig. 5 illustrates that only the owner or an administrator may install the engine in a particular Oracle user schema. This requires: "User name / password", "Server name", "Port" and "Database instance name". In addition, access to the local folder must be permitted, in which the OPCHSE engine as "obfKit1_1. jar »file is saved. After the loading process has started, the Loadjava engine confirms that all Java byte classes are loaded correctly in the selected database user account (= schema).
    Fig. 6 shows an example of an electronic masking and labeling engine according to the invention, which is completely embedded as Java byte code in the Oracle database. That Fig. 6 shows that with the help of common SQL tools (e.g. SQL Developer) the database contains all classes of the obfuscation engine. Only the JavaByte code is loaded into the database.
    7 shows an example of the table "OBP_PACKAGELIST_T", which contains the packets to be obfuscated. The order of the package names can be enforced. This preserves the logical reference of the PL-SQL packages and can be compiled without errors as an entire library. End users add the list of PL / SQL packages to be obfuscated to the table «OBF_PACKAUST_T».
    Fig. 8 shows an example of the table OBF_JKEYWRD2OBF_T, which contains the keywords to be encrypted in the column «KEYWORD». The engine determines the obfuscated keywords “on-the-fly” and saves them in the “OBFKEYWORD” column. Fig. 8 thus shows the second important table which is to be maintained by end users. The masking and labeling engine always generates an encrypted key word of 29 characters for each plaintext »KEYWORD» and stores it in the «OBFKEYWORD» column. In the case of cross-site scripting attacks (XSS), attacks using SQL injection on the database objects can be prevented. On the one hand, because the encrypted object names are not listed. Thus, brute force and / or rainbow password cracker methods prove to be useless for obtaining the encrypted keywords as plain text. On the other hand, if an object name is extended by just one character or the encrypted key words are manipulated, the PL / SQL engine reports an error immediately, because in the first case the Oracle engine does not allow object names longer than 30 characters and / or As in the second case, because the manipulated encrypted keyword remains undetected in the context of the PL / SQL source code and the Oracle PL / SQL engine stamps the object as "invalid", all execution is blocked immediately. Finally, total obfuscation of all object names is possible in order to counteract "snoopers" within the same company, in which all object names are encrypted both in the package definition and in the package body. In the search tree, e.g. SQL developer or using the usual administrator tools, sequences of meaningless character sequences appear. Only users and / or those who have maintained and developed the PL / SQL source code can use the table (see FIG. 8) and the same mechanism to create the plain text PL / SQL source code again. The encryption engine, which is available separately from the obfuscation engine, is therefore also or particularly suitable for scheduled or randomly controlled changes to passwords in distributed Oracle databases.
    The table (FIG. 8) can be extended in many respects such as historization, versioning of the encrypted keywords or passwords and license key management in a customer-specific manner.
    By exchanging the content from the "OBFKEYWORD" column with the content from the "KEYWORD" column, developers and owners of the PL-SQL code can use the same engine to obtain the plain text source code. Even after the complete obfuscation of all object names (package, procedure, function, table names) by entering the plain text names in the «KEYWORD» column, it is possible to exchange the plain text source code from the to gain encrypted source code. Even more, e.g. In order to safeguard and prove the intellectual property rights or other rights of a PL-SQL source code, any number of “electronic signatures” can be scattered in the obfuscated source code or placed as planned.
    Fig. 9 shows an example of embedding the Java programs in PL-SQL code and control from the PL-SQL code.
    Fig. 10 shows an example of a compact plain text PL-SQL source code.
    11 shows an example of a compact masked PL-SQL source code. Encrypted keywords replace the plaintext keywords. The compact plain text PL-SQL source code (see FIG. 10} forms the basis for the masking of the PL-SQL source code, as shown in FIG. 11.
    CH 712 679 A2
    Detailed description of a preferred embodiment variant FIG. 1 schematically illustrates an architecture for a possible implementation of an embodiment variant of the Oracle-based PL / SQL code hiding and signing engine. For example, the engine can be successfully implemented on various Oracle instances and platforms based on a library of 25 PL / SQL source code packages. The compiled PL / SQL source code of an entire library is always kept within the Oracle database. The entire functionality of the OPCHSE engine is based on compacting and sequencing (FIGS. 9 and 10) the source code, masking selected keywords (FIG. 8) within the PL / SQL source code (FIG. 11). The unique PL / SQL package names are stored as primary keys in a relational table within the Oracle database (Fig. 7). The order of the stored PL / SQL package names (Fig. 7) serves as a reference mechanism and order to compile the masked PL / SQL packages of a library into an Oracle RDBMS (Relational Database Management System) instance. This makes it possible to mask and compile an entire library within a few minutes, if not seconds, at the push of a button compared to Pete Finnigham's engine. It should be noted that relational databases are based on a table-based relational database model. The associated database management system is referred to as a relational database management system or RDBMS (Relational Database Management System). The database language SQL (Structured Query Language) is mainly used to query and manipulate the data. The basis of the concept of relational databases is the relation, i.e. Database relation, which represents a mathematical description of a table. Operations on these relations are determined by relational algebra. Relational algebra is the theoretical basis of SQL. The relational database is therefore based on a collection of tables (the relations) in which data records are stored. Each row (tuple) in a table is a record. Each tuple consists of a series of attribute values (i.e. properties), the columns of the table. The relation scheme defines the number and type of attributes for a relation.
    The keywords to be masked in the PL / SQL code are uniquely listed in a relational table and exactly assigned to a specific PL / SQL package. A corresponding engine reads the plain text keywords from the source code, generates them dynamically, i.e. "On-the-fly", an encrypted keyword according to the PL / SQL rules, replaces the plaintext keyword with the encrypted keyword and stores the entire, masked PL / SQLSource code piece by piece in a relational table (see Fig. 11). The encrypted keywords are irreversible for third parties, in particular hackers, because none of them are contained in any "list" or can be viewed.
    The tables with the original, compacted source code, sequence of the PL / SQL packages to be encrypted, encrypted key words and masked code can only be made selectively accessible to a protected group and e.g. only be accessible to those authors and / or developers who are tasked with the obfuscation task and / or who have agreed to maintain the IPR (Intelligence Property Rights) of the PL / SQL code. The protected group of people may even be obliged to provide proof if an end user is possibly using an unlicensed PL / SQL source code. The electronic masking and labeling engine enables the masked PL / SQL code to be “electronically signed”. This is done by deliberately inserting automated strings into the code using the engine, which are correctly interpreted by the Oracle PL / SQL Engine. In truth, the apparently "nonsensical strings" hide and clearly detectable the signing token as copyright proof. This technique of code signing using "nonsensical strings" can be used in particular to intentionally and deliberately prevent the execution of PL / SQL source code. This means that a protection mechanism can already be used when the source code is delivered in order to make either transactions, actions or operations on data in the database impossible and / or to implement the multi-eye principle, e.g. when it comes to selecting and handing over transactions and / or actions and / or sensitive information that require authorization, which must be confirmed beforehand by a wide range of co-responsible parties, by invoking a procedure / function / program whose name is also encrypted and appears as a result of «nonsensical» characters within the PL / SQL source code and is embedded. The hidden program, which is embedded as Java byte code in the PL / SQL code, blocks immediately before executing (i) transactions and / or actions that require approval for sensitive information, (ii) notifies (eg immediately) those responsible , e.g. Line manager, decision-maker and / or member of board, C-level, e.g. via common communication channels, such as iPhone, mail, telephone, about the intention to carry out an illegal transaction and / or action that was triggered by third parties. All process steps that the initiator of the transaction and / or action requiring approval has been irrevocably registered, frozen and encrypted. A copy of the entire registered process steps that led to the unauthorized transaction and / or action, similar to a black box in the aviation industry, are encrypted outside the system. The records can be used in particular as evidence for forensic purposes. With this mechanism e.g. Even hackers are unable to steal or manipulate data even after a successful intrusion into the system.
    The access to the respective user scheme (cf. FIG. 1, process step 3), which stores the entire electronic masking and labeling engine, takes place only by means of predefined, sharp roles which are assigned to certain, identified end users of the engine are, namely, according to the security rules of the database provider, ie e.g. from Oracle. The security of access to the electronic masking and labeling engine can even be increased significantly by the entire mechanism being “transparently encrypted” in the respective memory6
    CH 712 679 A2 medium and is integrated with the masked, created PL / SQL source code in the orderly backup-restore recovery process.
    After masking the source code, the masking and labeling engine allows it, either a single PL-SQL package (suitable for creating individual patches within a library) or an entire library as a single stream in a zipped file ready for dispatch , to export (see FIG. 1, process steps 4 and 5).
    Developers and / or author (s) of the PL / SQL code alone can reconstruct the pair (plaintext keyword; encrypted keyword) at any time using the historization and versioning mechanism and determine when, for which end user or customer in which PL / SQL package the substitution "plaintext keyword" with "encrypted keyword" took place (see Fig. 8). This means that for defined users, in particular those responsible for code and / or developers, i.e. the restricted group of those who are obliged to maintain confidentiality, it can be determined when, for which end user or customer, in which PL / SQL package the substitution plaintext keyword »with« encrypted keyword »has taken place. Likewise, in the same table (FIG. 8), in which each pair (plaintext keyword; encrypted keyword) is stored, each pair is provided with a time stamp. The whole mechanism can e.g. be developed in Java, an object-oriented programming language (Fig. 2, 3, 4). However, the engine is completely embedded as byte code (completely non-transparent and irreversible code for users) in the PL / SQL code and can be executed by the PL-SQL engine (cf. FIGS. 5, 6, 9). End users can e.g. operate the engine using common and well-known tools. In particular, the entire process from installation, troubleshooting to the creation of zipped patches or libraries ready for dispatch can be designed using a GUI (graphical user interface).
    The table, which contains the keywords to be masked (FIG. 8), can be filled in an analogous manner with plain text passwords. Then the encrypted on-the-fly, i.e. dynamically generated passwords are sent from machine-to-machine in order to change passwords automatically on local or delocalized (remote) machines and / or applications and / or according to a schedule and / or at random.
    Due to the automatically updated life cycle mechanism for each plain text password, application name, delocalized and / or local machine, security administrators always have a dynamically managed overview of when which password was changed and where.
    The inventive masking and labeling engine offers a valid countermeasure to make the cybercrime, which penetrates systems and databases with increasingly active and very sophisticated methods, more difficult, if not to prevent the craft. On the one hand, because the PL / SQL source code possibly encoded by hackers [using: "Brute Force", "Man-in-the-Middle", "key-loggers", "sniffing", methods to name examples] Keywords and / or passwords that are completely worthless for a hacker. There is no list with which the encrypted keywords can be compared to get the plain text. The inventive masking and labeling engine generates an encrypted keyword dynamically (“on-the-fly”) at random. The faster variant of the “brute force” process “rainbow password cracker” (see www.google.ch/ gfe_rd=cr&ei=Cb5EV7cluaX8QeCkYKQDw&gws_rd=ssl#q=rainbow+password+cracker) is completely useless for hackers in this case ,
    The inventive masking and labeling engine generates even a single character plain text keyword and / or password an encrypted keyword or password of 29 characters according to the PL-SQL Engine rules of Oracle. The maximum character length of 29 characters is specified by Oracle and must not be exceeded under any circumstances, because as soon as a single character is added to the encrypted character string, the Oracle PL / SQL Engine blocks any further execution. If hackers replace a single encrypted keyword themselves, this will not be recognized by the Oracle Engine in the context of the PL / SQL code. Every attempt to run a program is immediately acknowledged with an "ORA error". With this mechanism, which is inherent in every Oracle instance, any manipulated, masked PL / SQL source code immediately raises the alarm.
    The encryption engine is particularly suitable for scheduled or randomly controlled password changes in distributed Oracle databases, better known as Oracle Cloud. The table (FIG. 8) with the pair (plain text keywords; encrypted keyword) can be extended in a customer-specific manner with regard to historization, versioning of the encrypted keywords or passwords and license key management (FIG. 4).
    The encryption engine can also be implemented separately from the inventive masking and labeling engine (see FIG. 2) and can be embedded and operated using the same mechanism (see FIG. 5) in a PL / SQL code ( see Fig. 9).
    权利要求:
    Claims (12)
    [1]
    claims
    1. Electronic masking and labeling engine for masking and unique signing of database contents and database source code, wherein a database source code comprises SQL code and PL-SQL code as the host language, and wherein SQL commands at corresponding positions in the source code are integrated by procedure calls and / or as plain text commands, which are translated by a precompiler into procedure calls of the host language, characterized in that
    CH 712 679 A2 that by means of a loading process of the masking and labeling engine reads plaintext keywords from the source code and dynamically, in real time, generates an encrypted keyword according to the PL / SQL rules that by means of the masking and labeling engine the plaintext -Keyword is substituted with the encrypted keyword and the entire masked PL / SQL source code is saved piece by piece in a relational table, whereby the encrypted keyword can be interpreted correctly by the Oracle PL / SQL Engine.
    [2]
    2. Electronic masking and labeling engine for masking and unique signing of database contents and database source code according to claim 1, characterized in that character strings are automatically inserted into the code by means of the masking and labeling engine, the code with inserted strings from the Oracle PL / SQL engine interpreted correctly.
    [3]
    3. Electronic masking and labeling engine for masking and unique signing of database contents and database source code according to one of claims 1 or 2, characterized in that access to the respective user scheme, which stores the entire electronic masking and labeling engine, only by means of predefined, sharp roles, which are assigned to certain, identified end users of the engine.
    [4]
    4. Electronic masking and labeling engine for masking and unique signing of database contents and database source code according to claim 3, characterized in that the access to the respective user scheme, which stores the entire electronic masking and labeling engine, by means of the predefined, sharp Roles are performed according to the security rules of a respective database provider,
    [5]
    5. Electronic masking and labeling engine for masking and unique signing of database contents and database source code according to one of claims 3 or 4, characterized in that the access security to the electronic masking and labeling engine is increased by a mechanism «transparent encrypted »is stored in the respective storage medium and integrated with the masked, created PL / SQL source code in the orderly backup-restore recovery process.
    [6]
    6. Electronic masking and labeling engine for masking and unique signing of database contents and database source code according to one of claims 1 to 5, characterized in that after masking the source code by means of the masking and labeling engine either a single PL-SQL package , which is suitable to create individual patches within a library, or an entire library is exported as a single stream to a zipped file ready for dispatch.
    [7]
    7. Electronic masking and labeling engine for masking and unambiguously signing database contents and database source code according to one of claims 1 to 6, characterized in that for users of the PL / SQL code by means of a historization and versioning mechanism the pair (plain text keyword; encrypted keyword) can be reconstructed, whereby for defined users, in particular those responsible for code and / or developers who are obliged to maintain secrecy, it can be determined when, for which end user or customer, in which PL / SQL package the substitution plaintext keyword »with «Encrypted keyword» has taken place.
    [8]
    8. Electronic masking and labeling engine for masking and unique signing of database contents and database source code according to one of claims 1 to 7, characterized in that in the same table in which each pair (plaintext keyword; encrypted keyword) is stored, each Couple is timestamped.
    [9]
    9. Electronic masking and labeling engine for masking and unique signing of database contents and database source code according to one of claims 1 to 8, characterized in that the entire masking and labeling engine is realized in Java and / or an object-oriented programming language, the engine as byte code and as completely non-transparent and irreversible code for users is completely embedded in the PL / SQL code and can be executed by the PL-SQL engine.
    [10]
    10. Electronic masking and labeling engine for masking and unambiguously signing database contents and database source code according to one of claims 1 to 9, characterized in that the table containing the keywords to be masked can be filled in an analogous manner with plain text passwords, the encrypted and dynamically created passwords can then be sent from machine-to-machine in order to change passwords automatically on local or delocalized machines and / or applications and / or according to a schedule and / or at random.
    [11]
    11. Electronic masking and labeling engine for masking and unique signing of database contents and database source code according to one of claims 1 to 10, characterized in that the masking and labeling engine consists of a single character plaintext keyword and / or password an encrypted keyword or password of 29 characters according to the PL-SQL Engine rules generated by the Oracle Database, whereby the maximum character length of 29 characters is determined by the Oracle Database and cannot be exceeded, and where, if added, a character is added to the encrypted character string of the Oracle-PL / SQL Engine blocks any further execution.
    CH 712 679 A2
    [12]
    12. Electronic masking and labeling engine for masking and unique signing of database contents and database source code according to one of claims 1 to 11, characterized in that the encryption engine is implemented separately from the inventive masking and labeling engine and with the same mechanism in one PL / SQL code is embedded and operable.
    CH 712 679 A2
    CH 712 679 A2
    CH 712 679 A2
    CH 712 679 A2
    CH 712 679 A2
    CH 712 679 A2
    CH 712 679 A2 • y *
    类似技术:
    公开号 | 公开日 | 专利标题
    DE60204049T2|2006-01-19|SYSTEMS, METHODS AND DEVICES FOR SAFE DATA PROCESSING
    DE60200616T2|2004-11-04|Secured content objects
    DE60301782T2|2006-05-24|APPARATES AND METHODS FOR DECREASING ENCLOSED DATA BLOCKS AND FOR LOCATING THE ENCRYPTED DATA BLOCKS IN THE MEMORY AREA USED FOR IMPLEMENTATION
    EP2899714A1|2015-07-29|Secure provision of a key
    DE60127310T2|2007-12-20|DEVICE FOR PROTECTING DIGITAL DATA
    DE102004057490A1|2006-06-01|Computer code processing device has subroutine call allocation table that incorporates a security module that makes it impossible to link subroutine calls to the subroutine called
    EP1798653A1|2007-06-20|Method and device for protecting a program comprising a function block
    WO2003025758A2|2003-03-27|Device and method for establishing a security policy in a distributed system
    CH712679A2|2018-01-15|Electronic masking and tagging engine for masking and uniquely signing database content and source codes.
    DE10020050A1|2001-08-16|Access protected handling of electronic data uses coding unit and processor based local system
    WO2001047175A2|2001-06-28|Device for the password-protected handling of an electronic document
    WO2006119928A1|2006-11-16|Method for adding functionality to an executable first module of a program package
    EP2491513B1|2018-02-07|Method and system for making edrm-protected data objects available
    EP1839136A1|2007-10-03|Generation of a program code in a load format and provision of an executable program code
    DE102016224455A1|2018-06-14|Database index of several fields
    EP2915091A1|2015-09-09|Method for the protected deposit of event protocol data of a computer system, computer programme product and computer system
    EP3745287B1|2022-03-16|Protection of a software application
    DE102018005102A1|2020-01-02|Adaptive security updates for applications
    DE102017214584A1|2019-02-28|Method and device for protecting a device
    EP3786818A1|2021-03-03|Method for protecting a software application against unauthorzed use
    EP1105798A1|2001-06-13|Method, array and set of several arrays for protecting several programs and/or files from unauthorized access by a process
    DE102017214591A1|2019-02-28|Method and device for protecting a device
    EP1720096B1|2017-07-12|Method for adding functionality to an executable module of a program package
    DE102010040259A1|2012-03-08|Method for providing executable transfer program code for performing controlled transfer of data between domains, involves compiling executable transfer program code by workflow module, based on selected configuration parameter
    WO2006063876A1|2006-06-22|Method and device for encoding and for carrying out a software library
    同族专利:
    公开号 | 公开日
    CH712651A2|2018-01-15|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    法律状态:
    优先权:
    申请号 | 申请日 | 专利标题
    CH00857/16A|CH712651A2|2016-07-06|2016-07-06|Electronic masking and tagging engine for masking and uniquely signing database content and source codes.|
    [返回顶部]